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Abstract — We propose embedding executable code fragments 
in cryptographically protected capabilities to enable flexible dis- 
cretionary access control in cloud-like computing infrastructures. 
We are developing this as part of a sports analytics application 
that runs on a federation of public and enterprise clouds. The 
capability mechanism is implemented completely in user space. 
Using a novel combination of X.509 certificates and Javscript 
code, the capabilities support restricted delegation, confinement, 
revocation, and rights amplification for secure abstraction. 

I. Introduction 

The predominant way of providing discretionary access 
control in the cloud is through a combination of authentica- 
tion and access control lists. But such mechanisms are not 
without problems. People and even entire companies end up 
with accounts in many different places. While single-signon 
mechanisms exist, they are adopted sparingly. To deal with 
their many accounts, people often use the same user name 
and password everywhere, or variations on a password that 
are easy to generate {e.g., "mypwd4amazon"), but also easy 
to reverse engineer. A malicious administrator at one site can 
then access accounts of users at other sites. 

This problem with access control list became apparent while 
developing Muithu [91, a sports analytics application that runs 
on a federation of public and enterprise clouds. A wealth of 
performance data is being collected in real-time by teams, 
sports media, and spectators. Careful analysis of such data 
is a crucial part of competitive sports. Much of the data is 
private and highly sensitive; this includes medical performance 
data, internal individual performance evaluations, and future 
training strategies. 

An important part of Muithu is abstraction. Raw data from 
various sources are processed and made available in another 
form, so that multiple layers of abstraction can be developed. 
With access control lists, each layer would need to have 
accounts with the lower layers, and also keep track of accounts 
of its own users and manage who is allowed to access which 
data. Much of the complexity then revolves around securely 
managing user accounts and correctly configuring the access 
control lists. Access control lists make it difficult to maintain 
fine grained control over distribution and access of data. 

The mechanism we propose here does not require au- 
thenticating any users because authorization is done through 
capabilities. Capabilities are unforgeable digital tokens that 
can be passed around, and possession of a capability grants 
specific rights to services independent of who the possessor 
is. Consistent with the Principle of Least Privilege, capabilities 



are given out on an as-needed basis. Capabilities have been 
used in a variety of systems. The instantiation of capabihties 
that we propose is novel in a variety of ways: 

• the capabilities contain embedded code that allow fine- 
grained control over restricted delegation. In other words, 
the set of rights that can be delegated is not predefined 
as in most capability-based systems but can be evolved 
as needed; 

• to support secure abstraction, the proposed capabilities 
support rights amplification; 

• no special trusted language, trusted operating system 
kernel, or other trusted infrastructure is required — the 
capabilities are managed completely in user space using 
public key cryptographic techniques; 

• even though managed in user space, transfer of capabil- 
ities is implicitly mediated so that confinement can be 
supported; 

• a directory service provides a secure way for users 
to manage their capabilities, and to delegate restricted 
capabilities to other users. 

We call these capabilities "code capabilities" or codecaps for 
short. 

II. Secure Abstraction 

Notational Analytics has become a competitive advantage 
for many elite sport coaches resulting in an emerging sport 
analytics industry. Example data include physical variables of 
individual athletes like speed, distance covered, agility, energy 
consumption, and muscle force. Such objective physical data is 
acquired using body-area sensors and from vision algorithms 
parsing video feeds. Additional data is added by expert ana- 
lysts like whether a soccer pass was successful or not and how 
well a team is performing. Major team sports like baseball, 
basketball, and soccer are avid users of such analytics systems. 

In close collaboration with a Norwegian major-league soc- 
cer club, we developed Muithu, a cloud-based notational 
analytics system for recording and analyzing soccer team 
performance data. A key requirement for Muithu was the 
ability to externalize collected data to third parties that, for 
instance, specialize in complex sports analytics. Also, a recent 
trend is to publish performance data on social media and 
more traditional broadcasting channels. A new generation 
of sport viewers familiar with social networks and micro- 
blogs tend to prefer this type of information while watching 
sport events. For instance, during the last European soccer 
championship in June 2012, major broadcasters distributed 



real-time performance data on social media platforms and 
traditional television broadcasts while games unfolded. This 
included statistics about successful passes, number of corners, 
attempted shots on goal, meters covered by individual players 
and the like. Obviously, there are strong security constraints 
related to athlete and team performance data. In particular, 
medical related information like heart-rate and injuries are 
highly personal and cannot be made public. 

The architecture of Muithu is designed to simplify the devel- 
opment of new sports analytics applications while observing 
security requirements from the ground up. One can think 
of Muithu as consisting of layers of abstraction. Each layer 
implements its own services and supports operations through 
a remote procedure call mechanism. Access to data is mediated 
through codecaps. Services are run by principals; clients that 
access services are principals as well. 

The base-layer of Muithu consist of captured notational 
data, video feeds, and sensor data that are pushed to and 
stored on an enterprise cloud platform through a REST API. 
This set of data, hosted by the base-layer principal Pq, is 
represented as a set of data objects that can be accessed 
through a simple interface. Such data objects may, for instance, 
correspond to raw sensor data of individual players in the 
team, and might be updated as new data about that player 
becomes available. Additional layers are then added as the data 
is being processed and tagged. Some layers have significant 
cloud resources available, but others work more like a library 
executed by their clients, often using JavaScript in the browser. 
The cloud resources of such layers are only accessed when the 
library cannot handle requests itself. 

As an example, consider the situation where a team coach 
Pi wants to provide up-to-date information about each player 
object o to the local supporter club P2. However, Pi has no 
interest in running a large web site to share this information. 
Instead, Pi can obtain a codecap ci from Pq for o and give P2 
a library and a delegated codecap C2 for o. When P2 invokes 
the library, the library can use C2 to access the current version 
of o directly from Pq and generate the derived object o' using 
the client's computational resources. Code in C2 ensures that 
P2 can only access those parts of o that Pi allows it to access. 

Now suppose that there are certain proprietary operations 
on o that Pi does not want to distribute in the library itself or 
using parts of the data in o that Pi does not want P2 to access 
directly. For instance. Pi might not want to give access to 
detailed heart-rate information, but instead provide only access 
to aggregated values. In that case the library can accesses a 
service run by Pi to execute the operation using codecap C2, 
as illustrated in Figure [T] Pi cannot use C2 directly to access 
o because it does not have the corresponding private key and 
because it does not give the necessary access rights. However, 
as we shall see. Pi can reconstruct ci from C2 and pair the 
resulting code cap with its own private key to obtain the correct 
access credentials to o. This is a case of rights amplification, a 
necessary ingredient of secure abstraction. It is not necessary 
for Pi to keep around all the intermediate codecaps, which 
would be inconvenient and waste computing resources. 
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Fig. 1. Muithu data layering example 

In general, abstraction often involves more than one object, 
and consequently more than one codecap. When a client 
requests an object, it obtains both a library for the object and 
the collection of codecaps that the library needs to access the 
underlying data for the objects. Only clients need to keep track 
of codecaps, as rights amplification allows the lower layers to 
reconstruct them as necessary. This much simplifies building 
secure cloud services compared to one based on access control 
lists in which user accounts must be managed and credentials 
for lower layers must be stored. 

III. Code Capabilities 

The implementation of codecaps is based on standard cer- 
tificate chains. Each principal P is identified by its public key 
P.pubkey and has a corresponding private key P.privkey 
that it keeps carefully hidden from other principals. In order 
for a client to execute a request as some service, the client 
needs a codecap for the request. 

A codecap c„ is a pair (/i„,fc„) consisting of a heritage 
and a private key. The heritage /i„ is a chain of public key 
certificates [Ci :: C2 '■■ ■■■ ■'■ C„] corresponding to a chain of 
n + 1 principals PQ...Pn. (The operator :: denotes list concate- 
nation.) In this case, Pq has delegated certain rights to Pi, Pi, 
has delegated rights to P2, and Pn-i has delegated rights 
to Pn- Certificate Ci is signed by fci_i = Pi_i.privkey. fc„ 
is the private key of P„. Codecap c„ is owned by principal 
Pn and gives access rights to services provided by principal 
Pq. However, Pq does not have access control lists, does not 
need to know anything about P„, and only needs to maintain 
its private key feg. 

Each certificate Ci is a collection of attributes signed by a 
private key. An attribute is a pair consisting of a name and 
a value. We denote by Ci.attr the value of the attribute 
named "attr" in certificate Ci. Each certificate Ci has at least 
the following attributes: 

• Ci.pubkey: contains P^-pubkey; 

• Ci. rights: contains a boolean function that takes a 
request as argument and returns true iff the function 
allows the request. 

Note that the validity of a heritage can be checked by anybody 
who knows Pp-pubkey, and that the private key fc„ in the 



codecap is the private key corresponding to the last certificate 
Cn on the heritage. A request is itself a certificate, signed by 
kn = -Pn-privkey. In some sense the request is appended to 
the end of the heritage as a certificate C„+i as if delegated. 
The attributes in the request describe the request type and its 
various parameters. Principal Pq will execute the request only 
if heritage hn is valid, the request's signature can be verified, 
and if Ci.rights(r) holds for all i in l...n. 

Principal Pq determines the programming language in which 
the rights functions are expressed. The language can be very 
simple. For example, a file service might have a language that 
consists of only three programs: "R", "W", and "RW". When 
the program "R" is applied to an update operation, it evaluates 
to false. 

We intend the language to be Turing-complete and to 
provide powerful library functions, such as JavaScript. For 
example, say that a file service only provides "read" and 
"write" operations and we want to create a codecap that can 
"increment" an integer that is stored in the file. The client 
would first read the file and then write back the incremented 
value. The rights function in the codecap would check that 
the value that is to be written is an integer that is one higher 
than the integer stored in the file. Rights functions may also 
be able to read the clock on the server. This can be used to 
implement expiration times on codecaps, or, for example, to 
specify that an operation is only allowed during daytime. 

It is important that such rights functions cannot have ex- 
ternal effects (such as writing files or sending messages) and 
that the functions have finite running times. They must be 
carefully sandboxed; loops and recursion may be disallowed 
and rurming times may be limited by a timer. 

IV. Using CodeCaps 

To illustrate how codecaps are used, suppose a client P„ 
has a codecap c,, for a service provided by Pq and wants Po 
to execute a request r. To do so, cUent P„ sends a message 
m to Po that contains the following attributes: 

• m. request: a certificate that described the requested 
operation and is signed by P„.privkey; 

• TO. heritage: contains hn, the heritage of the codecap 
needed to execute the request. 

Upon receipt of a message to,, Po verifies the her- 
itage, and verifies the signature on the request certificate 
using C„.pubkey. Pq then checks that all rights func- 
tions Ci.rights(TO. request) return true. For exam- 
ple, a rights function might express to. request. type = 
READ A TO.request.of f set > 256. If verified, Pq exe- 
cutes TO,. request and returns the result to client Pn- 

Note that an eavesdropper on the network may intercept 
the request message and obtain the heritage of the codecap. 
However, without the corresponding private key, the eaves- 
dropper will not be able to sign new requests with it. The 
eavesdropper can replay the request — it is thus important that 
either the service is capable of eliminating duplicates or that 
requests are idempotent. In practice, communication between 



a client and a service is usually over SSL, eliminating this 
concern. 

There are two ways in which a codecap can be created. 
The first is from scratch, when a new service is offered or 
a new client is added. The second is by (possibly restricted) 
delegation, in which case a client communicates one of its 
codecaps to another principal. Note that only heritages of 
codecaps are communicated between principals — the recipient 
of the heritage of a new codecap has to complete the codecap 
by pairing it with its private key. 

We illustrate here how confinement can be achieved. A 
principal P„ can create a codecap for P„+i so that P„+i 
cannot delegate rights of that codecap to other principals 
without revealing its private key to those principals. The idea 
is that the rights function in certificate C„+i has the ability 
to test if it is the rights function of the last certificate in the 
heritage of the codecap, returning false if not. If P„+i is 
faulty it can share its private key with other principals, but this 
does not extend the damage from having delegated to Pn+i 
in the first place. 

When confined, a principal P„ that wants to delegate to a 
principal P^ must ask one of the principals on the heritage 
of the codecap to generate a codecap for P^. In the limit, a 
service may choose to confine all its codecaps and thus be 
involved whenever delegation takes place. 

V. CodeCap Directories 

Clients and services may end up owning many codecaps. All 
codecaps of a principal have the same private key, which the 
principal has to maintain securely. To simplify management 
of all the heritages and delegation, we are developing a 
distributed directory service. Directories are objects that map 
string names to codecaps. However, different from ordinary 
directory services, a "lookup" operation is a restricted delega- 
tion: the directory service delegates its rights to its client. 

A directory has rows and columns. Both rows and columns 
have names. There are no two rows with the same name, and 
no two colunms with the same name. The first column is called 
"name" and contains the name of the row. The second column 
is called "cap" and contains the heritage of a codecap in each 
row. The remaining columns contain rights functions. Each 
such column is called a group. Directories support an operation 
"chmod" by which rights functions in the group colurmis may 
be updated. The execution of the chmod operation itself is 
restricted by rights expressed in the directory codecap. 

A directory codecap gives access to one or more groups 
within a directory. Given a directory codecap dc, the operation 
lookup{dc, name, group) first finds the row for the given name. 
In the row it retrieves a heritage /i„ in the "cap" column and 
the rights function R in the given group. The directory service 
then delegates its rights given by /?„ by appending a new 
heritage /i„+i using R and signed by the private key of the 
directory service. The directory service then returns the result 
to the cUent, which uses /i„+i and its private key to construct 
a codecap. 



Since directories are objects themselves, they may be or- 
ganized in any arbitrary directed graph structure (it does 
not have to be a tree and can contain cycles). A user then 
needs to hold only one codecap, that of its "home directory". 
Given the codecap of its home directory, all objects reachable 
from that directory, subject to the restrictions specified in the 
rights functions, are accessible to the user. Note that it is not 
necessary that all directories are serviced by the same physical 
server. In a large scale system there may be many directory 
servers in different geographical locations. 

We do not run public directory services, however, as this 
would be tantamount to simulating access control lists using 
codecaps. Directories are privately owned by principals and 
run by those principals to keep track of their own codecaps 
and to help with delegating codecaps to other users. 

The directory service library supports path names of the 
form "/a/b/c". The library maintains two directories: that of 
the home directory and that of the working directory. Path 
names that start with "/" are evaluated relative to the home 
directory while other path names are evaluated relative to the 
working directory. Initially the home directory and the working 
directory are the same. A library "chdir" method updates the 
working directory. 

VI. Revocation 

The "chmod" operation (as well as the "remove" operation) 
on directories provide a means to do selective revocation, 
preventing users from obtaining codecaps. However, codecaps 
that have already been distributed remain valid. Various ways 
have been proposed to revoke outstanding capabilities. (For 
an early approach, see fTTl .) One is to associate version 
numbers with objects fT^. A codecap would be for a version 
of the object, and certificate Ci would contain the version 
number the codecap refers to. When a service wants to 
invalidate outstanding codecaps on one of its objects, it simply 
increments the version number of the object. (This technique 
may also be used for key rotation or dealing with lost private 
keys.) 

This only works for the raw objects. If an intermediate 
service wants to revoke delegated codecaps, it must ask the 
provider of the raw object to increment the version number 
Selective revocation can be supported with this scheme by 
having multiple version numbers per object, that is, one 
version number for each group of principals. Alternatively, 
services can build expiration times into the rights functions 
of codecaps as described above. Clients should think of such 
codecaps as "soft references" that may at any time become 
invalid. Those clients should be prepared to acquire new 
codecaps when necessary. 

Another revocation technique exploits indirection. An inter- 
mediate service, instead of passing out delegated codecaps, 
could generate fresh codecaps and act as a proxy to the 
service that provides the raw objects. Such a scheme also 
supports selective revocation in which only a subset of clients 
are affected. This proxy scheme complicates the intermediate 
service (in a similar way as maintaining access control lists) 



and consequently has security disadvantages compared to the 
simple scheme of revoking all outstanding codecaps. Whether 
to use one scheme or another can be determined by each 
application individually. 

A weakness of codecaps compared to access control lists 
is that there is no way to review which principals have rights 
to a service One option is for a service to confine all 
its codecaps so it is involved in and can keep track of all 
delegation. 

VII. Object Lifetimes 

So far we have only considered operations on objects (and 
services) that already exist. We now turn to how objects are 
created at a service run by some principal Pq, and how such 
objects can be garbage collected when there are no more 
outstanding references (codecaps) to those objects. A client 
typically needs a codecap with/acfory rights in order to create 
new objects. For example, a directory server may distribute 
codecaps with factory rights that can be used to create new 
directories. For convenience, codecaps for factory objects may 
be available in special "yellow pages" directories that are 
referenced by well-known codecaps. 

When principal Pq receives a "create" request from a 
principal Pi, it checks to make sure that Pi has factory 
rights. If so, Pq creates a new object and a corresponding new 
heritage hi containing a certificate Ci that specifies the rights 
that Pi gets on the object. Service Pq then sends heritage hi 
to Pi, which adds its private key in order to obtain a codecap 
ci for the object. 

The dual of creation is garbage collection, a difficult prob- 
lem in distributed object systems as it is hard to identify 
which objects are no longer reachable. We present a partial 
solution here. The idea is that every object has a "primary 
link" consisting of a directory codecap and a name. If there 
is a codecap for the object stored in the corresponding row of 
the directory, then the object persists. If not, then the object 
is eventually destroyed. (An object may optionally support 
multiple primary links.) 

To implement this, the service that provides the object 
periodically checks the object's primary link to see if it still 
points to the object. If so (or if directory is unavailable), 
then the object persists. Otherwise, the object service destroys 
the object. If a directory service is discontinued, then there 
may be a set of objects that have dangling primary links. 
Those primary links are stored in "lostH-found" directories. 
These directories are checked and cleaned up manually by 
an administrator. 

VIII. Implementation 

Our prototype implementation of codecap authorization is 
based on standard X.509 certificates [3J using the widely 
adopted OpenSSlHl library and tools. The X.509 standard 
defines several standard fields in certificates including a subject 
name, an issuer name, and validity dates. It enables us to 

' http://www.openssl.org 



make use of RSA, DSA, and ECC, with varying key sizes 
and parameters. We use established best practices. Certificates 
can be either self-signed, in which case a PKI is not required, 
or signed by a common trusted CA. 

A codecap heritage is implemented as list of concate- 
nated X.509 proxy certificates as defined in the RFC-3820 
standard |13|. This standard defines the proxyCertlnfo cer- 
tificate extension containing three fields: path length, pol- 
icy language, and policy. The path length C.pLength is 
used to restrict the length a heritage and can be used to 
implement confinement. The policy field holds our rights 
functions C. rights (expressed in JavaScript), and the policy 
language C.pLanguage is set to anyLanguage to indicate 
application-specific policies. 

Certificate size varies with key size, signature algorithm, 
and with the size of the information used to identify subject 
and issuer. A certificate may also contain extensions with 
variable content length. A typical PEM encoded certificate 
combining 2048-bit RSA public key with SHA-1 and with 
common extensions like subject key identifier, authority key 
identifier, and usage constraints, will be about 1.2 KB. In the 
more compact DER binary representation, the same certificate 
is 0.86 KB. 

Currently we do all communication over SSL, since it 
is widely adopted on the Internet for server authentication 
using X.509 certificates. By requiring that the optional client 
authentication step of the SSL handshake is run, both end- 
points will mutually authenticate themselves to each other The 
protocol also provides us with transport level encryption. 

After establishing the mutually authenticated SSL connec- 
tion and having received the server certificate Cs, the client 
can check that it is connected to the right service. The client 
is free to reject certificates that do not conform to additional 
constraints like a valid expiration date or set usage areas. If 
the client accepts the connection, it will transmit the heritage 
in combination with its intended request. 

Although SSL supports transmission of more than one 
certificate from the server to the clients during the handshake, 
its intended use is to inform the client about trusted CAs, and 
there is no facility for transferring extra certificates from the 
client to the server. Therefore, a codecap containing multiple 
certificates cannot be transferred and validated during the SSL 
handshake and codecaps must be validated separately. 

Having received the client certificate Cc, the heritage /i„, 
and the request r, the server will check that: 

• C„. public — Cc-public (to ensure that the client is 
correctly authenticated); 

• for i = 1, . . . , n — 1, Ci.sub ject = Q+i. issuer (to 
ensure that the heritage is correctly chained); 

• for z = 1, . . . , n — 1, C^.pLength > C^+i.pLength > 
(sanity check); 

• the signature of each certificate verifies with the issuer's 
public key. 



var allow = heritage [ idx] . get_subject (). CN; 
if (request. uri == allow) 1; else 0; 

Fig. 2. A simple JavaScript based rights function 

We have enhanced the Twisted-Pythor0 web-server module 
with codecap-based authorization. To transfer the heritage, we 
extended the commonly used HTTP authentication mechanism 
with a codecap credential method. The client authenticates 
itself by setting the header field: 

Authentication: Codecaps <heritage> 

where <heritage> is the list of PEM encoded X.509 
certificates. If the header is not provided or the heritage does 
not validate correctly the server returns a "401 Unauthorized" 
error code and includes the header: 

www-Authenticate: Codecaps realm=<sub> 

where <sub> corresponds to Po-subject and is used by 
the client to identify the correct codecap to use. If the same 
codecap is used to authorize multiple requests, the server may 
temporarily store the provided heritage and use a client-side 
session cookie to decrease network overhead. 

To evaluate the rights function we use the Firefox Spi- 
derMonkejl^ JavaScript engine. When executed, the script is 
initialized with the following context: 

• heritage — a list of X.509 certificate objects; 

• idx — the position in the heritage list of the certificate 
currently being evaluated; and 

• request — the client request. 

Figure |2] shows a simple rights function that matches the URI 
of the client's request with any path restrictions encoded in 
the common name field of the certificate. 

IX. Related Work 

Dennis and Van Horn |4| first used the term "capability" for 
an unforgeable access token. Many capability-based systems 
have been built, but they usually rely on a trusted runtime 
environment in order to prevent forging of capabilities and to 
mediate communication of capabilities. Chaum |2| presents the 
first cryptographic approach to capabilities that does not make 
such an assumption. The Livermore Network Communication 
System |5| and the Amoeba distributed operating system ITOll 
adopted and improved on this approach lfT2l . Amoeba also 
contained a directory service for capabilities. However, such 
capabilities cannot be confined in any way and rights that can 
be delegated are predefined. Codecaps build on this work, but 
supports fine-grained rights delegation through embedded code 
and supports confinement by embedding a private key in each 
codecap. 

The capability mechanism proposed by Harnik et al. fH 
uses keyed cryptographic hashes in a way similar to Amoeba 
and supports delegation by chaining hashes. Each entry on the 

' http://tvifistedmatrix.com | 
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chain can contain regular expressions to express which rights 
are being delegated. The mechanism is less expensive than our 
approach, but does not support rights amplification and cannot 
be used for secure abstraction. The MyProxy service [l] uses 
X.509 proxy certificates to delegate credentials, but lacks fa- 
cilities for including and evaluating complex rights functions. 

Amazon Web Services and Microsoft Azure support 
capability-like URLs for use in the cloud, which contain 
a query, an expiration time, and a signature. The query is 
similar to the embedded code of rights functions in codecaps. 
However, the URLs cannot be confined or be delegated in a 
restricted manner, and the mechanisms do not support rights 
amplification. 

X. Conclusion 

We have proposed codecaps as a flexible way of providing 
discretionary access control in the cloud. We are developing 
this as part of a sports analytics application that runs on a 
federated cloud environment. Codecaps are essentially certifi- 
cate chains corresponding to the chain of delegation, but has 
the novel property that they may contain boolean JavaScript 
function that checks whether a requested operation is allowed. 

Using codecaps, we have demonstrated how it is possible 
to do fine-grained rights delegation, confinement, and rights 
amplication as needed for secure abstraction layers. We have 
also shown various solutions to revocation. Users can maintain 
codecaps and facihtate their delegation using codecap direc- 
tories. 

We have not yet finished the implementation of our codecap- 
based access control infrastructure, but soon hope to present 
experiential data on its effectiveness. 
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